軟體專案是資助和組織軟體開發的熱門方式。它們將工作組織成臨時的、僅建置團隊，並透過商業案例中預測的特定效益獲得資金。產品模式則使用耐用的、構思-建置-執行團隊來處理持續的業務問題。產品模式讓團隊能夠快速重新定位，縮短端對端循環時間，並透過使用短週期迭代來驗證實際效益，同時維持軟體的架構完整性，以維持其長期效能。

當面臨需要更換現有軟體系統時，組織常常陷入半完成技術更換的循環。我們的經驗教導我們一系列模式，讓我們能夠打破這個循環，依賴於：對取代傳統軟體的預期成果的深思熟慮、將此取代分為數個部分、逐步交付這些部分，以及改變組織文化，以認知到變更是不變的現實。

為了有效利用技術，我們需要將我們的技術思維與基礎業務計畫相符。技術策略可以推動此項調整，前提是它適當地整合業務和技術。我們已開發一個概念架構，以協助我們進行此策略性思考，其基礎是認知策略性計畫的共同面向，讓我們找出十一種普遍的策略性方向。對於每個方向，我們概述它們提出的關鍵業務問題，以及我們需要進行的調查，以探討技術影響。我們發現此架構不僅可以制定更有效的技術策略，還能讓技術為業務思考提供資訊，開發新的收入來源。

良好的技術設計決策非常依賴於背景。定期共同為共同目標而努力的團隊能夠定期溝通並快速協商變更。這些團隊展現出強大的力量，並且可以做出利用這種強大的力量的技術和設計決策。當我們在一個較大的組織中縮小範圍時，在獨立工作且較少頻繁合作的團隊和部門之間存在越來越弱的力量。認識到這些強弱力量的差異，使我們能夠做出更好的決策並為每個層級提供更好的指導，從而讓團隊能夠更快速地行動。

架構不一定是獨白；由少數集中的人員從上而下傳達。本文描述了另一種執行架構的方式；作為一系列對話，由分散且強大的決策制定技術推動，並由四種學習和調整機制支援：決策記錄、諮詢論壇、團隊來源原則和技術雷達

模組化架構可以改善軟體交付嗎？可以！- 但有一些但書。本文記錄了一家企業的旅程，他們著手將其架構轉移到更模組化的架構，以緩解其成長的痛苦。他們發現模組化是一個多方面的解決方案，不僅限於架構，還延伸到業務溝通、團隊拓撲和有效的開發人員體驗。透過密切注意這些因素，該企業能夠顯著提升其行動應用程式的交付效能。

Xapo 創立時是一家比特幣服務供應商，後來發展成一家線上銀行。在這個轉型過程中，它需要重新評估其軟體資產，並建立一個架構能力來引導其未來。它採用了領域驅動設計、團隊拓撲和架構建議流程中的想法，來開發一個架構建議論壇。這讓其軟體交付團隊更為一致，並制定了一個連貫的技術策略。

商業整合工具現在已經有幾十年的歷史了，但在描述何時以及如何使用它們時，幾乎沒有什麼總括性的架構原則。在本文中，我認為「購買」決策機制導致我們誇大了此類工具的價值主張，通常會導致強制使用某個整合工具，而不是通用語言。我認為此類工具在將整合視為主要連接系統的世界中蓬勃發展，但數位組織已重新構想整合，使其主要在數位功能前放置乾淨的介面，強調功能而非系統。最後，我列出了一些現代整合觀點背後的主要原則，並聲稱它們最適合使用通用語言來管理，重新導向商業整合工具的主要價值主張，以簡化戰術實施問題。

基礎架構平台團隊讓組織能夠透過使用有彈性的解決方案來解決常見產品和非功能性需求，進而擴大交付。這讓其他團隊可以專注於建立自己的事物，並為其使用者釋出價值。但沒有人說建立可擴充的平台很容易... 在本文中，Poppy 和 Chris 探討了 7 個關鍵原則，可以幫助你正確建立正確的事物。提示：不要跳過策略、使用者體驗和研究。

在 DevOps 文化中整合必要的安全控制和審計功能以滿足合規性要求，可以利用 CI/CD 管線自動化，但隨著組織規模擴大，會出現獨特的挑戰。了解所選實作的次要影響和意外後果，是建立有效、安全且可擴充解決方案的關鍵。

當組織採用敏捷思維時，企業架構並不會消失，但企業架構師的角色會改變。企業架構師不再做出選擇，而是協助其他人做出正確的選擇，然後傳達這些資訊。企業架構師仍需要形成願景，但接著需要在團隊之間建立橋樑，以建立學習社群。這些社群將允許團隊探索新方法並相互學習，而企業架構師則是這些成長的合作夥伴。

我們和我們的同事經常被要求為我們的客戶執行架構評估。當我們這樣做時，參與這些系統的架構師會討論這些系統的效能、它們對故障的復原力，以及它們如何設計成輕鬆支援新功能。然而，很少出現的大象是不同系統如何為商業價值做出貢獻，以及這個價值如何與這些其他架構屬性互動。

許多大型組織看到他們的 IT 引擎與執行長辦公室隔了許多樓層，這也將業務和數位策略與執行這些策略的重要工作分開。架構師的主要角色是在頂樓辦公室和引擎室之間搭電梯，在任何需要支援這些數位工作的樓層停靠：自動化軟體製造、將前期決策降到最低，以及在技術演進的同時影響組織。

建築能耗中很大一部分用於減少或避免鎖定。這是一個相當崇高的目標：建築的目的是為我們提供選擇，而鎖定則相反。然而，鎖定並非一個簡單的真或假問題：避免被鎖定在一個方面通常會將你鎖定在另一個方面。此外，諸如開源自動消除鎖定的流行觀念並非完全正確。是時候仔細了解鎖定了，這樣你就不會被避免鎖定的觀念所束縛！

大多數內部 REST API 都是一次性的 API，專門為單一整合點而建置。在本文中，我將討論非公開 API 所具有的限制和靈活性，以及從跨多個團隊進行大規模 RESTful 整合中學到的經驗。

在理想狀態下，產品模式組織由鬆散結合、自主的團隊組成，這些團隊能快速回應已表達和未表達的使用者需求。然而，偶爾會出現需要跨多個團隊協調回應的機會。如果沒有有效管理，結果將導致收入損失、客戶不滿意和團隊能力浪費。我們將回應這些機會的組織性舉措稱為專案。在本文中，我們將透過一個專案失敗的範例來分享我們在產品模式組織中管理專案的經驗。

當客戶公司購買軟體產品時，他們通常需要熟練的人員來安裝這些產品。這些人員通常由服務供應商公司提供，因為軟體產品供應商認為建立自己的服務部門沒有商業意義。客戶需要了解產品供應商和服務供應商之間的關係，並應要求與他們合作的供應商公開這種關係。隨著雲端供應商的崛起，這些合作夥伴關係日益重要，因此公開性也越來越重要。

企業架構群組通常與日常開發分開。這可能會導致他們對開發工作的知識過時，而開發團隊沒有採取廣泛的企業觀點。我的同事（Thoughtworks CTO）麗貝卡經常看到這種情況發生，她認為企業架構師可以透過加入開發團隊來發揮更大的效用。

在 2008 年的舊金山 QCon 大會上，麗貝卡·帕森斯和我做了一個演講，說明敏捷方法如何與企業架構群組合作。目前，敏捷專案團隊和架構群組之間存在許多不信任和衝突。我們深入探討其原因，並探索這些群組可以合作的方式。

最近，我的同事尼爾·福特、麗貝卡·帕森斯和帕特·庫亞合寫了一本名為《建立演化架構》的書。我很榮幸他們邀請我撰寫序言。

許多企業正在投資其下一代資料湖，希望能大規模民主化資料，以提供商業見解，並最終做出自動化智能決策。基於資料湖架構的資料平台有常見的故障模式，導致無法大規模實現承諾。為了解決這些故障模式，我們需要從湖泊或其前身資料倉庫的集中化範例轉變。我們需要轉變為從現代分散式架構中汲取的範例：將網域視為首要考量，應用平台思維來建立自助式資料基礎架構，並將資料視為產品。

康威定律（由梅爾文·康威於 1968 年制定）指出，系統的設計受到其設計人員的溝通模式的限制。Birgitta、Mike、James 和我討論了此原則的含義，以及我們在職業生涯中如何看到它的發揮。我們討論了它對微服務概念的影響、與業務能力保持一致的重要性以及逆向康威操作的角色。

軟體開發中尚未解決的問題之一是決定軟體的界線為何。（瀏覽器是否為作業系統的一部分？）許多服務導向架構的支持者相信應用程式將會消失，因此未來的企業軟體開發將會是將服務組合在一起。

我不認為應用程式會消失，因為應用程式界線很難畫出的原因相同。基本上，應用程式是社會建構

我在軟體架構中所推崇的幾乎所有從業人員都對該領域的任何一般定律深表懷疑。良好的軟體架構非常特定於情境，分析在各種環境中以不同方式解決的權衡取捨。但如果有一件事他們都同意，那就是康威定律的重要性與力量。它足夠重要，可以影響我遇到的每個系統，而且它足夠強大，以至於如果你試圖與它抗爭，你註定會失敗。

在每個正常規模的團隊中，將任何類型的技術的替代方案選擇限制為三個。這些是：當前合理的預設值、我們正在試驗的試驗值，以及我們討厭並想要退役的值。

最近我在 Amazon 上看到幾則關於 P of EAA 的負面評論，因為書中沒有提到企業架構。當然，這是有原因的 - 這本書是關於企業應用程式架構，也就是如何設計企業應用程式。企業架構是一個不同的主題，探討如何將企業中的多個應用程式組織成一個有條理的整體。

每當 Thoughtworks 冒然讓我面對客戶時，我一定會被問到「你對 SOA（服務導向架構）有什麼看法？」這個問題幾乎不可能回答，因為 SOA 對不同的人來說有不同的意義。

任何大型軟體專案，例如大型公司的軟體資產，都需要很多人手 - 而每當你擁有很多人手時，你都必須找出如何將他們分成有效率的團隊。組成以業務能力為中心的團隊有助於軟體專案對客戶需求做出回應，但所需的技能範圍常常讓這些團隊不堪負荷。團隊拓撲是描述軟體開發團隊組織的模型，由 Matthew Skelton 和 Manuel Pais 開發。它定義了四種形式的團隊和三種團隊互動模式。該模型鼓勵健康的互動，讓以業務能力為中心的團隊在提供穩定且有價值的軟體任務中蓬勃發展。